home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1993 July / InfoMagic USENET CD-ROM July 1993.ISO / sources / std_unix / archive / text0079.txt < prev    next >
Encoding:
Text File  |  1993-07-06  |  3.6 KB  |  95 lines
  1. Submitted-by: berg@pool.informatik.rwth-aachen.de (Stephen R. van den Berg)
  2.  
  3. It seems that POSIX 1003.1 describes the semantics for setgid() in
  4. such a way that they *needlessly* cripple certain applications.
  5.  
  6. As I understand it, POSIX 1003.1 specifies a very useful construction
  7. called "saved user and group ids".
  8.  
  9. The saved ids principally get set whenever a process performs an execve()
  10. call.  This first causes the effective ids to be set according to the settings
  11. on the binary being executed, and shortly thereafter, the saved ids are
  12. copied over from the effective ids.
  13.  
  14. This allows graceful switching between the real ids and the saved ids,
  15. because both the real and saved ids will not be affected by subsequent
  16. setuid() and setgid() calls, only the effective ids are changed.
  17.  
  18. So far, so good.  Then I notice a small problem on the horizon.  When the
  19. program performs a setgid() while the effective uid of the process is zero,
  20. this not only affects the real and effective gid, but it ALSO affects the
  21. saved gid.
  22.  
  23. Now I can't imagine any program making use of or depending on this
  24. (mis)feature.
  25.  
  26. Sure, I heard the classical argument, programs like "login" and "su" need
  27. to be able to set the saved gid of a process to prevent security holes.
  28. But that is not true.  They do not need to set it at all.  It would be
  29. more than sufficient if both su and login could only set their real
  30. and effective gids.  When they then subsequently execve() the following
  31. shell (or other program), the saved gid will *automatically* be copied
  32. from the effective gid.
  33.  
  34. Why do I care, you might wonder.  Well, consider the following:
  35.  
  36. -rwsr-sr-x  1 root     mail        49152 Mar 12 18:19 /local/bin/procmail
  37. drwxrwxr-x  2 root     mail         1024 Mar 12 18:24 /usr/mail
  38.  
  39. If procmail is called by user A who is in group B, it then has to
  40. assume the identity of a completely other user (the recipient) in order
  41. to deliver the mail.
  42.  
  43. Say the recipient is user C in group D.
  44.  
  45. Then the following SHOULD happen to the ids while it is executing:
  46.                             (- means no change)
  47.  
  48. Previous event:            uid    euid    suid    gid    egid    sgid
  49.  
  50. Start procmail            A    root    root    B    mail    mail
  51. initgroups() for user C        -    -    -    -    -    -
  52. setgid(D)            -    -    -    D    D    mail
  53. setuid(C)            C    C    C    -    -    -
  54. access some files for user D
  55. start programs for user D
  56. setgid(mail)            -    -    -    -    mail    -
  57. create a file in /usr/mail
  58. setgid(D)            -    -    -    -    D    -
  59. access some files for user D
  60. start programs for user D
  61. exit
  62.  
  63.  
  64. Now, POSIX says that the saved gid changes to D as well when the first
  65. setgid(D) is executed (because the euid is zero).  This makes it *impossible*
  66. to somehow flip back the gid to "mail", like I try to do in the second
  67. setgid() call.
  68.  
  69. But, I can't delay this setgid(D) call till after the setuid() call because
  70. then I may no longer have permissions to join group D.
  71.  
  72. This raises these questions:
  73.     - Why did POSIX specify it the way it did?  Any compelling reason?
  74.     - Is there any (fictitious) program that depends on the semantics of
  75.       setgid() being so that it affects the saved gid when being root?
  76.     - Is there any way to accomplish this flipping between two groups
  77.       that I overlooked?
  78.     - If not, can we do anything about the standard (to fix this, I can
  79.       not imagine even one program breaking if we do)?
  80.     - What about this rumoured setrgid() or setregid() call?  Would that
  81.       exhibit the correct behaviour?  Or does it exhibit these
  82.       braindamaged semantics (affecting the saved gid when root) as well?
  83.  
  84. Any comments/answers/hints appreciated.
  85.  
  86. -- 
  87. Sincerely, berg@pool.informatik.rwth-aachen.de
  88. Stephen R. van den Berg (AKA BuGless).    berg@physik.tu-muenchen.de
  89.  
  90. I've never been superstitious!  Knock on wood.
  91.  
  92.  
  93. Volume-Number: Volume 31, Number 82
  94.  
  95.